Real-time activity monitoring and reporting

ABSTRACT

In order to track activities in a computerized system with client-server or other communications, a system configuration is needed which monitors, logs and reports traffic. This is somewhat akin to but not entirely similar a firewall. Thus, the invention contemplates a real-time, platform-independent, rule-based activity monitor for detecting a particular activity of interest as it occurs and for reporting such activity and the user substantially as fast.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Non-Provisional patentapplication Ser. No. 11/230,987 filed Sep. 19, 2005 (Attorney Docket No.MIC-246) entitled “Real-Time Activity Monitoring and Reporting,” whichclaims priority to U.S. Provisional Patent Application No. 60/707,630filed Aug. 11, 2005 (Attorney Docket No. MIC-246P) entitled “Real-TimeActivity Monitoring and Reporting,” which are incorporated herein byreference for all purposes.

FIELD

The present invention is related to monitoring of computer user behaviorand more specifically to real-time, rule-based monitoring and reportingof activities which trigger events of usage of enterprise applications.

BACKGROUND

Network traffic is often regulated in that not all traffic is allowedaccess through a network. Much depends on the network infrastructure andits security settings and tools for controlling access. Traffic innetworked computer systems is often controlled by firewalls thatintercept Internet or other network communications to prevent intrusionof those communications that are unwanted.

At the same time, there are communications that are seemingly legitimateand authorized to access the network through the firewall but areotherwise improper. Communications are defined as being improper if theydefy certain rules or create an irregularity or risk to theorganization. One example of improper communications between an end-user(client) and a host involve access for the purpose of obtaining privateor privileged information in contravention of the organization's usualoperating procedures. Another example of improper communication betweenthe client and host is a security breach, where an un-privileged user(e.g., employee) gains access and makes unauthorized changes to companyrecords. Then again, a legitimate and proper communication maynevertheless be of interest and therefore targeted for analysis andreporting. Such legitimate communications may include informationrelevant to the operations of an organization somewhere remote orenterprise-wide.

Hence, in order to track these improper or targeted communications, asystem configuration in needed which monitors and reports traffic. Thisis somewhat akin to but not entirely similar a firewall.

One approach to tracking and detecting improper or targeted networkcommunications, involves a system for real time monitoring of end-userand administrator communications and communication patterns(collectively “activity”) using configurable business rules fordetecting exceptions that indicate such activities. This system tracksall users in the mainframe server environments, e.g., iSeries systems,IBM 5250 or 3270 mainframes or AS/400 mid-range system environments orother client-server based systems such as ERP (enterprise resourceplanning) and packaged applications. This approach non-invasively tracksand records all user activity in legacy applications while creating alog or field-level audit trail of activity, where recorded data(activity log) is ciphered and digitally signed, thus beingcourt-admissible. The system monitors any type of activity regardless ofthe host's operating system (OS/390, VSE, VM, OS/400, etc.) and thedatabase used by the applications is transparent (including DB2, IMS,ADABAS, VSAM, etc.). The system runs on a separate server whichintercepts communications between end-users and hosts by sniffingnetwork transmissions through a network switch. The real time sniffingof transmission through a network switch creates an activity log thatcan be later accessed to retrieve evidence of improper, irregular, riskyor simply targeted communications.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention contemplates, as oneapproach, a simpler-than-switch-based sniffing implementation and a moreexpedient access to the activity information. Thus, by comparison to aconventional firewall, an activity monitor contemplated by the presentinvention can be viewed as an ‘application layer firewall.’ Thisapplication layer firewall functions as a real-time,platform-independent, rule-based activity monitor (“Monitor”) fordetecting a particular activity of interest as it occurs and forreporting such activity and the user substantially as fast.

Whenever any of the monitored activities is identified as having met oneof the rules, and is therefore one of the triggering application usageevents, the monitor so indicates and initiates an action. Reporting andsaving an activity report to a log are examples of the types of actionsinitiated by the monitor when rules are met (i.e., activity meets ruleis TRUE). A system administrator can define the rules and actions byusing the actual user interface of the particular enterpriseapplications. For instance, the user interface of an applicationpresents fields or any other data structures and those that are ofinterest can be selected in the process of creating rules and actionsthat will be associated with the triggering event. Upon being defined,the rules and actions are deployed to the monitor for subsequentrun-time usage.

The Monitor can be deployed into a legacy system without modifying itsexisting components or imposing any overhead on the legacy applications,and by being transparent to the server and client applications theMonitor lets network traffic pass through without disturbingcommunications flow between the host and clients.

In operation, the Monitor parses and based on the rules evaluates theclient-server traffic (e.g., between a host and clients or betweenapplication programs in the same or different computers). The Monitorflags and reports in real time any activity or event communicatedto/from the host which meets one of the rules. The Monitor can identifythe source and destination of the activity and its nature while beingentirely transparent to the traffic source and destination. Forinstance, the rule may include a text string with the name of a personwanted by authorities or of an activity forbidden under accountingpractices. The Monitor can also be deployed for business management bymonitoring business activity. Hence, the Monitor is useful forregulatory compliance, e.g., Sarbanes Oxley, law enforcement, businessactivity such as supply chain management, insurance and finance.

In one implementation, the Monitor is deployed into the network betweena main frame and clients that run emulators such as the RUMBA®3270/5250/VTXXX emulator, an AttachmateWRQ Reflection™ or any othercomparable facility. In another implementation, the Monitor is deployedin an enterprise application interface (EAI) between two systems, sayTibco's EAI between a CRM system and a logistics system, or between twoenterprise applications that interface with each other using protocolssuch as SOAP Web Services. In these implementations, the Monitor is akinto a proxy gateway (where to the client the Monitor looks like a serverand to the server the Monitor looks like a client; neither one of themsenses the Monitor's presence).

Alternatively, the Monitor is implemented as a local proxy deployed onthe user PCs instead of the servers and where the downstream reportingand alerting duties are offloaded to an actions server. In other words,each client receives an instance of the local proxy and reports itsfindings to an action server for further downstream reporting. The rulesengine in each instance of the local proxy is deployed to seamlessly andnon-invasively observe and analyze, in real time, all traffic passingthrough the OS (operating system) layers toward the network adapter.

Preferably, the rules evaluation is implemented in these embodiments isa separate process or thread with lower priority. This way, the rulesevaluation impose virtually no delay on the traffic between the clientand the server. In other words, consistently, including during rulesevaluation and actions triggered by targeted activities, the Monitormaintains transparency to the client and server. To this end, theMonitor allows creation and attachment of an XML instruction file withthe rules for capturing events of interest.

Thus, in accordance with the purpose of the invention as illustrated andbroadly described herein, the present invention provides variousembodiments of a system and method for real-time activity monitoring andreporting.

Various system embodiments can be directed to real-time activitymonitoring and reporting. One such system includes a host having anapplication; a client in communication link with the host, and a Monitorbetween the client and the host. The client has an emulator associatedtherewith through which the client is capable of interacting with andexchanging communications with the application via the host. The Monitorhas traffic, rules and actions engines where the traffic engine is forsubstantially real-time sniffing and parsing of all communicationsbetween the client and the host, the rules engine is for substantiallyreal-time evaluation of parsed communications, and the actions engine isfor substantially real-time reporting of communications deemed to meetpredetermined rules by the rules engine, wherein the Monitor istransparent to both the client and the application running on the host.In this embodiment, the host is deployed in a machine, such as themachine is a server, a mainframe, or a super-computer, and the Monitoris also deployed in that machine, although the Monitor is logicallyinterposed between the host and the client.

A client can be a product that communicates directly with the host usinga similar method. Thus, another system embodiment includes a hostmachine having a host and an application; an actions machine having anactions engine; and one or more user machines having a client, anemulator and a Monitor instance. Each client is in communication linkwith the host and capable, with their respective emulator, of exchangingcommunications with the application via the host. Each Monitor instancehas traffic and rules engines where each traffic engine is forsubstantially real-time sniffing and parsing of all communicationsbetween a respective client and the host, each rules engine is forsubstantially real-time evaluation of parsed communications, and theactions engine is for receiving alerts from the rules engines and forsubstantially real-time reporting of communications deemed by such rulesengines to meet predetermined rules. Again, the Monitor is transparentto each of the clients and the application running on the host. In thisembodiment, the actions machine is a server and the host machine is aserver, a mainframe or a super-computer.

A third system embodiment includes a first machine having a firstapplication; a second machine having a second application; and anapplication interface interposed between the first and second machinesand having a Monitor which is in communications link with the first andsecond applications. The Monitor has traffic, rules and actions engineswhere the traffic engine for substantially real-time sniffing andparsing of all communications between the first and second applications,the rules engine for substantially real-time evaluation of parsedcommunications, and the actions engine for substantially real-timereporting of communications deemed to meet predetermined rules by therules engine. Here again, the Monitor is transparent to both the firstand second applications.

This and other features, aspects and advantages of the present inventionwill become better understood from the description herein, appendedclaims, and accompanying drawings as hereafter described.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings which are incorporated in and constitute apart of this specification illustrate various aspects of the inventionand together with the description, serve to explain its principles.Wherever convenient, the same reference numbers will be used throughoutthe drawings to refer to the same or like elements.

FIG. 1 is a system architecture diagram showing top-level details of aMonitor interconnected between hosts and clients.

FIGS. 2-6 illustrate various embodiments of an activity monitoring andreporting system.

FIG. 7 illustrates the relationship between screens and conditions.

FIGS. 8-18 are screen shots of the user interface for creating rules,conditions and actions.

DETAILED DESCRIPTION

As mentioned above, the present invention is based, in part, on theobservation that there is a need for more expedient detection andreporting of improper or simply targeted activity. Thus, it is importantto first understand where this need might exist and how such need mightbe met by a system configured in accordance with an embodiment of thepresent invention. To illustrate, we will examine a number of use cases.

Oftentimes, mission critical operations involve distributed branches andremote employees or affiliates using desktop or mobile devices thatcommunicate with central systems. In such environment, transactions suchas financial fund transfers, health-care and insurance queries andupdates, CRM operations and manufacturing and retail warehouse movementsare conducted via a wide spectrum of technologies, accessing centralhosts and corporate-centric systems.

Consider for instance a manager in a financial service organization, orany other type of organization, who wishes to monitor businessactivities of the organization (BAM—Business Activity Monitoring). Thegoal of BAM is to allow the manager to perform the work more efficientlyby monitoring processes within that manager's responsibility. Themanager might want to record a specific event where, say, a certainamount of money higher than a pre-defined value is entered via a givenapplication. This manager might want to have a ‘dashboard’ whichprovides a real-time view of the operations across several branches andseveral applications running on the bank's IBM Mainframe host.

So, to illustrate how it works, we assume that this manager logs on tothe host and invokes a particular application, using the emulator.Looking at a screen associated with the particular application, themanager then clicks on the field or fields to which rules will beattached. The manager then goes through a “wizard”—a sequence of dialogwindows that help in defining what to check (what rules and conditionsto impose) and what to do if the check returns a positive value (as willhe later explained in connection with FIGS. 6-16). After defining therules, assuming this manager has the proper authorization, the rules areuploaded to the Monitor (e.g., OnWebIT™ appliances) and from that momenton the rules are applied to all screens associated with the application.

In the next example, also involving BAM, employees in a manufacturingfloor enter into an AS/400 station the various hourly status andlogistics needs. Managers on upper level floors and the headquarterswould like their dashboard to show or alert them, in real time, on anyirregularity or if any predetermined threshold is reached, which mightproject on the wider logistics outlook. Those thresholds can changedynamically, so rules for detecting events that meet or trigger thesethresholds should be easily defined. For this purpose, an implementationof the present invention will allow definition of the rules withoutunderstanding the underlying technology or data structure, by simplyusing the application interface.

In an example involving IRS operations, we suppose that an IRSsupervisor noticed someone from the inside looking up celebrity filestoo frequently. Internal affairs would like to know which station isused in this activity in order to track the internal breach of privacy.The IRS offices use a program written in COBOL and DB2 database whichare deployed on the central mainframe. Thus, with a system in accordancewith the present invention, the manager will define a rule formonitoring the activity. To this end, the manager will go to theplanning tool, defining the screen where a file is searched (or defininga family of screens using a common denominator such as text on thescreens). This rule might indicate that access needs to be flaggedwhenever a name out of a given list of celebrity records is searched.The access will be flagged by writing the user-id, the station (client,PC) address, time and date, and any details (e.g., type of access) intoa secured central file, and by reporting to the monitoring tool (e.g.,action server).

In the example involving a banking environment, we envision CRM(Customer relations management) audits. The call-center for a bankallows active recruitment of new customers, promotion of value addedservices via telemarketing campaigns, and quality of serviceimprovements. However, systems which are accessed by the operators andcustomer representatives via emulators and hold the actual customer dataare host driven and not ready to'be customer-centric. In this case, thebank would like to: notify the CRM of any customer related activitytaking place in one of the legacy applications running on the Mainframe;have managers get notification whenever a predetermined condition is met(such as a new customer account was created and more than $100,000 wheredeposited); and create an audit log because the company is subject toSOX (Sarbanes Oxley) audits, which requires recordation of specificactions onto the audit log for later analysis. The SOX reporting offinancial activities is required to prove full control over theoperational flow of financial activities; and the financial institutionuses the present invention to further verify the integrity of suchreports.

In the example involving intelligence services there is a supposedthreat by militant groups that oppose the presence of armed forces intheir country. For this example we assume further that this extremistgroup is getting confidential information from an internal source, say,the name and address of high ranking field commanders. The intelligenceservice would like to record any query in the system relating to theconfidential information. Then, the system is required to monitor thetraffic, report immediately, and record all communications which involvethis data, including which station (user, client) has accessed this dataand under what credentials.

In yet another example involving insurance operations, we assumereal-time messaging into the CRM via legacy applications. Suppose thatan international insurance company deploys a new CRM center while agentsand doctors are still using, directly or indirectly, legacyemulation-based screens. The CRM is implemented using modern technologysuch as .Net or J2EE and is supposed to receive a message for everycustomer information update entered via the legacy platform. The Monitoris thus useful for this purpose.

Next, in the context of financial credit and risk control management(for cash flow control), various services, such credit-card services,trust management services, and gold accounts and private bankingservices, require maximum control over the assets for which they areresponsible. However, it is hard to achieve instantaneous detection oftransactions, or even trends, such as excessive credit card usage,suspicious transactions against a limited account, or irregular tradingof certain stock in view of exchange limits. By using a systemconfigured in accordance with an embodiment of the present invention,new predetermined rules as well as customized rules can be transparentlyapplied to existing systems without any code change to the legacy systemand without jeopardizing ongoing business.

In the context of value-added services, while monetary holdings, savingaccounts and payment clearing services yield stable interest revenuesfor financial institutions, such organizations are constantly lookingfor ways to increase customer retention, improve their competitiveadvantage, and offer new revenue-generating services. This goal is hardto achieve since most services are based on existing bankinginfrastructure and the proprietary homegrown systems of the variousbanks. A system embodying an instance of the present invention allowsplug and play services to be based simply on the behavior of legacysystems. Such service might be as simple as email alerts, where, forinstance, card holders can command a self-service web site to provideemail notifications to their mobile device whenever certain balance isreached in their personal account or certain activity occurs in relationto this account.

In yet another example, a manager responsible for productions in a carmanufacturer's facilities requires notifications on his windowsdashboard of any changes in car dealership orders that impacts theproduction line schedule. The production line involves a verycomprehensive process that includes many subcontractors and schedulingand that is based on parts, colors, destinations and due-dates. Anychange in orders, such as color change for a specific model order, mightimpact the entire line. The manager needs to be constantly informed inorder to make the right decisions at the right time.

In the context of public safety and police force operations, someonemight be leaking confidential information from the internal mainframeapplication. To breach security, someone must gain access to theconfidential information with various discrete or even continuousqueries via this application. With a system configured in accordancewith an embodiment of the present invention, by introducing a specificrule, an internal affairs detective can immediately deploy a way to, inreal-time, trace and catch the suspects.

Likewise, in the context of homeland security, the department ofhomeland security would need security alerts, with client addresses, onany Internet searches that somehow include targeted search terms (e.g.“explosive”). With deployment of the present invention, the publiclibrary, based on an IBM host can be tracked without changing orapplying any new technology in the existing system. The alerts will besent directly to the department's central alerts system.

In many of these environments regulations control operations and protectprivacy, such as in healthcare. For this purpose, the Monitor provides anon-intrusive, rule-based engine that can explore usage of, say, amedical records management system and provide alerts on any suspect ornon-compliant activity using such system.

In view of the foregoing, it is easy to understand the benefits that canbe derived from a real time activity monitoring and reporting facilitysuch as the Monitor. The description below outlines implementationsdetails of the Monitor in accordance with principles of the presentinvention and its various embodiments.

In general, when a user wants to connect to host, such as IBM 5250 and3270-based Mainframe computers, or an AS/400 server, the user opens anemulator and enters in the connection parameters the Internet address ofthe host whose resources the user wants to access (the host to which theuser wants to log on). The host allows many different computers that runclient software and use Internet resource called Telnet tosimultaneously access its resources. Telnet clients are available forall the major operating systems. When establishing communications withthe host, the client and host use proper Telnet protocol, afterdetermining which terminal emulator will be used. Terminal emulationmaps the keyboard and display functionality in a manner suitable for theparticular situation.

Then, when communications flow a firewall typically intercepts andcontrols access of communications traffic. To monitor and reporttargeted activity in this communications traffic, however, the presentinvention provides the Monitor (in one implementation or another). Bycomparison to the firewall, the Monitor can be more closelycharacterized as an “application layer firewall.”

To illustrate, some of the fundamental differences between the Monitorand a firewall involve the aspects of how traffic is blocked, where thefacility is deployed, its capacity, connectivity and traces. Forinstance, a firewall requires understanding and use of protocols and thelike, while the Monitor is easily deployed through the actualapplication or visual browsing of the service (web-service, API). Also,a firewall is intrusive in that it blocks the traffic and usesaccess-based rules, while the Monitor is non-intrusive and usesrule-based evaluation of traffic without impacting such traffic. Afirewall is deployed between the outside world and the private network,while the Monitor is deployed between applications and/or between hostsand clients inside private networks. Then, firewalls examine all trafficwhile the Monitor examines specific traffic, for instance 3270 terminalstraffic. With a firewall, alerts are stored internally and shown usingproprietary GUI, while with the Monitor an action is connected to theactual operational systems, reporting, emails, BPM, etc. Finally, with afirewall traces are stored in the form of stream of bytes which are notdirectly unreadable, while with the Monitor traces are true applicationimages, compressed and encrypted to secure privacy and efficiency.

Various system configurations can be implemented with the Monitor. Thus,FIGS. 1-6 illustrate a number of system configurations in accordancewith the principles and various embodiments of the present invention.

FIG. 1, is a system architecture diagram showing top-level details of aMonitor interconnected between hosts and clients. In this systemconfiguration 10, the Monitor 11, is located in front of the host system12. Examples of host systems include mainframes such as the iSeries orIBM 3270/5250 or midrange such as the AS/400. Because the Monitor 11impersonates the host 12, client applications such as emulators 15(unknowingly) access the Monitor via the host's IP address. Indeed, theMonitor establishes a connection with the host system for each clientsession that connects to it.

It is noted the client sessions can be recoded in memory such as disk(e.g. RAID). Then if the rule or action call for it, a session can bereplayed to discover the particular activity or trend of interest.

As can be seen by the up-down arrows, the data streams directly betweenthe clients and host without interference from the Monitor 11. Then, ina separate thread which, optionally, involves another CPU or server, acopy of the data stream is obtained and evaluated (as shown by theleft-to-right arrow). Using a 1-bit delay fall-through traffic engine 18and an application analyzer 19, the Monitor obtains and analyzes, inreal time, the data streams relative to the protocol being employed(e.g., 3270 or 5250). User activity represented within these datastreams is examined by the application analyzer 19 using a rule-basedevaluation. The rules are expressed in XML (extensible markup language)format 20 where they are created at planning time 22 by the user orsystem administrator directly from the application user interface. Thereal time actions engine 21 is prompted into a predefined action when arule-based evaluation returns a TRUE condition evaluation result. Theaction engine 21 commences the action substantially without delay, withthe exception of CPU wait time to give priority to a connection task.Therefore, the rules evaluation and action are said to he handledvirtually in real time.

For performing the predefined action, such as remote notification,reporting, security alert, or saving to a log file, the actions enginereceives all the necessary information about the activity that triggeredit. This information includes the session information and the triggeringactivity information along with information on the condition associatedwith it. Thus, in essence, the Monitor described above can be viewed ashaving three functional engines: a traffic capture engine, a rulesanalysis engine and an actions engine.

In this configuration, the Monitor is deployed for working with serverssuch as the Red Hat Enterprise, Linux, IBM Host-Publishing, MicrosoftHIS, and Microsoft Windows 2003 servers. Optionally, the Monitor isprovided with code that includes a complete installation script,recovery procedures, and backup and restore utilities. The Monitor isfurther deployed with capacity to hold hundreds of concurrent sessionsand hundreds of rules applicable to tens of different recognizable itemssuch as application screens. For the database and file reporting actionsthe Monitor is provided in a system with a large RAM (e.g., 2 GB), alarge cache (e.g., 2 MB), two redundant power supplies and a networkingcard (or a Giga network interface). The activity log file records thedata in ciphered format using an encryption algorithm (e.g., 64/128 bitencryption). The foregoing configuration is scalable for allowing morerules, additional sessions, etc.

FIGS. 2 and 3, show in more general terms various implementation whichare possible in accordance with the principles of the present inventionand which apply to client-host communications using emulators asdescribed above. In one instance, the so called ‘application layerfirewall,’ or Monitor as it is referred to here, is akin to a proxygateway that is deployed between the user's emulator and the host(although in reality it is installed as a software program on the serverwhich embodies the host). To the clients the Monitor looks like the hostand to the host the Monitor looks like the clients. As illustrated, thehost can operate under any type of operating system in a mainframe (100,FIG. 2) or a server (101, FIG. 3). In the shown embodiments, the Monitor102 includes a traffic capture engine 120, a rules analysis engine 122,and an action execution engine 124. The traffic capture engine 120parses the communications based on the particular protocol to extractthe information payload. The rules engine 122 evaluates the parsedcommunications based on the rules, and the actions engine 124 performsan action in connection with the targeted communication.

The monitor can work in the presence of any operating system and, inthis way, the Monitor is indeed platform independent. The Monitor canhandle 3270/5250 protocols or it can add a plug-in for accommodatinganother protocol such as JDBC (database access protocol), libRFC and RC(remote function calls), web services (SOAP/WS protocol), HL7, HTTP, andothers. A protocol plug-in is a software module that ‘teaches’ thetraffic capture engine 120 in the Monitor 102 to parse new types ofcommunications (protocols and formats). The plug-in applies also to adesign-time tool 1.0 (not shown) that allows the end-user to view theirapplications screens the way they normally would, and at the same timeattach rules to various screen locations in it.

As a proxy gateway, the Monitor 102 does not disturb the communicationwith the host. The Monitor sniffs (acquires a copy) but otherwise letsthrough all communications that flow between the host and the user'scomputer. With the rules engine 122, the Monitor applies the rules tothe parsed communications to detect targeted communications. To thisend, the Monitor holds in the rules engine 122 a set of instructions,rules, that instruct it what to look for and what to do with the trafficit observes. For a targeted activity that meets a parameter of one ofthe rules, the Monitor recognizes the location (host, application,screen) at which a user is in and, in connection with this activity, theMonitor checks for other values of fields that the user's communicationsprovided. It evaluates these values against pre-set conditions, and ifthe entries are deemed to meet the conditions in the rule, this findingtriggers the required action, which is also specified inside theinstructions.

For each scenario, there are various conditions that represent athreshold, an irregularity, a point of interest or a risk that aredefined by the rules. The rules can apply to multiple screen “locations”in the application by specifying a common locator indication, therebycreating a “family” of screen elements to he monitored and analyzedsubject to a predetermined rule criteria. For example, every screen thathas the phrase “enter command:” should be checked for a user-typedcommand that includes “explosives.” With the Monitor, the user candefine, at planning time, the conditions under which an activity will bechecked against a rule. Such conditions can include the direction inwhich communications should be check in (client-to-host, host-to-clientor bidirectional).

The principles of the present invention allow easy definition of suchconditions through user interface. Furthermore, the list of possibleconditions is extendable, and new rule types can be added by using theJava-Reflection or a similar mechanism to add new code to an existingworking system. The new code can be referenced via an XML file, or aBPEL-WS format can be used as the XML schema. The addition is visible toa rules planning-time tool in the system, and the XML code containsinstructions such as how to build the user-interface for the newconditions. The new rules, incorporated in an XML instruction file, areloaded onto the Monitor for their subsequent run-time application toprogram usage events.

The Actions to be performed by the action execute engine 124, when acondition inside a rule is met, are extendable in the same way thatconditions are. The system includes a wide range of pre-defined actionssuch as: write to a file; write an entry to a database; call aweb-service; interact with a process schema; notify a monitoring toolvia SNMP (MIB) or other means; send an email; send SMS; update adashboard; record any further activities for this session; activate abusiness process; plug into an EAI (enterprise application interface)bus; report to a fraud detection system or to a fraud detection system;report to an activity or audit log (who, where, what, when); send a JMSmessage; send a message to a TP (Transactional Processing) server (suchas MQSeries, MTS, JMS etc.); re-play activities log; and record thissession from now on to an encrypted (ciphered) and compressed location.

Moreover, if one were to add new code to the server which defines, forinstance, a new action, this code can be added as a module (packaged asa JAVA, C, or C++ module). The new ‘action’ module can be referenced inan XML instruction and put to the test through a certification programto verify that it works as intended and does not interfere with theoperation of other rules or adversely effect the server. Once suchmodule is certified, the reference to it can be dynamically added to theplanning (design time) tool and run time engine of the Monitor. In otherwords, the set of rules, conditions and actions can be modified orextended dynamically.

Incidentally, in order to “teach” the firewall a new rule one would haveto understand technical terms like port, protocol, packets etc. Bycontrast, the Monitor advantageously allows the user to simply use theoriginal application and define the rules, conditions and actions on thefly. Those rules are then saved and can be uploaded to the Monitor as anXML file and be effective immediately. Here are few examples of XMLfiles with rules and action definitions.

<?xml version=“1.0” ?> <actions> <dynamicactiontype=“com.netmanage.OnWebIT.navigator.common.SendMail” name=“Send Mail”description=“When the action is performed, will send an email to thedesignated person/people.” > <parameter type=“string” name=“to”description=“Use a ‘;’ or a ‘,’ as a seperator between emailaddresses.”></parameter> <parameter type=“string” name=“from”description=“Use a ‘;’ or a ‘,’ as a seperator between emailaddresses.”></parameter> <parameter type=“string”name=“subject” ></parameter> <parameter type=“string”name=“body” ></parameter> <parameter type=“string”name=“smtp-server” ></parameter> </dynamicaction> </actions>

<?xml version=“1.0” ?> <conditiontype=“com.netmanage.OnWebIT.navigator.common.InStringList” name=“InString List” Description=“Looks first in second based on seperator.Supports trimming and ignorecase”> <parameter type=“string” name=“first”/> <parameter type=“string” name=“second” /> <parameter type=“boolean”name=“ignorecase”><![CDATA[true]]></parameter> <parameter type=“string”name=“delimiter”><![CDATA[,]]></parameter> <parameter type=“boolean”name=“trim”><![CDATA[true]]></parameter> <text> <![CDATA[In StringList]]> </text> </condition>

<?xml version=“1.0” encoding=“us-ascii”?> <nav:screenxmlns:nav=“http://wwww.netmanage.com/NAV” columns=“80” rows=“24”fieldCount=“44” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“http://wwww.netmanage.com/NAV.\schemas\NavigatorScreenXML_Schema.xml” name=“NewCustomerScreen”><nav:cursor column=“22” row=“9” /> <nav:fields> <nav:fieldname=“field--1--1” attribute=“1” color=“blue” column=“1” row=“1”length=“2”><![CDATA[ ]]></nav:field> <nav:field name=“field-1-3”attribute=“1” color=“white” column=“4” row=“1” length=“5”><![CDATA[File]]></nav:field> <nav:field name=“field-1-9” attribute=“1”color=“white” column=“10” row=“1” length=“71”><![CDATA[ Help]]></nav:field> <nav:field name=“field-2-1” attribute=“1” color=“blue”column=“2” row=“2”length=“80”><![CDATA[------------------------------------------------------------------------------]]></nav:field> <nav:field name=“field-3-2” attribute=“1” color=“blue”column=“3” row=“3” length=“27”><![CDATA[NEW ]]></nav:field> <nav:fieldname=“field-3-30” attribute=“1” color=“blue” column=“31” row=“3”length=“131”><![CDATA[New Customer ]]></nav:field> <nav:fieldname=“field-5-2” attribute=“1” color=“green” column=“3” row=“5”length=“79”><![CDATA[Add the details then press Enter to validate thedata. Then use the ]]></nav:field> <nav:field name=“field-6-2”attribute=“1” color=“green” column=“3” row=“6”length=“160”><![CDATA[Save option in the File pull-down to store it.]]></nav:field> <nav:field name=“field-8-3” attribute=“1” color=“green”column=“4” row=“8” length=“17”><![CDATA[Account Number :]]></nav:field><nav:field name=“field-8-21” attribute=“1” color=“turquoise” column=“22”row=“8” length=“32”><![CDATA[00000246 ]]></nav:field> <nav:fieldname=“field-8-54” attribute=“1” color=“green” column=“55” row=“8”length=“28”><![CDATA[Allocated by System ]]></nav:field> <nav:fieldname=“field-9-3” attribute=“1” color=“green” column=“4” row=“9”length=“17”><![CDATA[Surname . . . . ]]></nav:field> <nav:fieldname=“field-9-21” attribute=“1” color=“turquoise” column=“22” row=“9”length=“20”><![CDATA[ ]]></nav:field> <nav:field name=“field-9-42”attribute=“1” color=“blue” column=“43” row=“9” length=“40”><![CDATA[]]></nav:field> <nav:field name=“field-10-3” attribute=“1” color=“green”column=“4” row=“10” length=“17”><![CDATA[First Name . . .]]></nav:field><nav:field name=“field-10-21” attribute=“1” color=“turquoise”column=“22” row=“10” length=“20”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-10-42” attribute=“1” color=“blue” column=“43” row=“10”length=“40”><![CDATA[ ]]></nav:field> <nav:field name=“field-11-3”attribute=“1” color=“green” column=“4” row=“11”length=“17”><![CDATA[Address . . . . ]]></nav:field> <nav:fieldname=“field-11-21” attribute=“1” color=“turquoise” column=“22” row=“11”length=“30”><![CDATA[ ]]></nav:field> <nav:field name=“field-11-52”attribute=“1” color=“blue” column=“53” row=“11” length=“30”><![CDATA[]]></nav:field> <nav:field name=“field-12-3” attribute=“1” color=“green”column=“4” row=“12” length=“17”><![CDATA[Town . . . . . ]]></nav:field><nav:field name=“field-12-21” attribute=“1” color=“turquoise”column=“22” row=“12” length=“20”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-12-42” attribute=“1” color=“blue” column=“43” row=“12”length=“40”><![CDATA[ ]]></nav:field> <nav:field name=“field-13-3”attribute=“1” color=“green” column=“4” row=“13”length=“17”><![CDATA[County . . . . ]]></nav:field> <nav:fieldname=“field-13-21” attribute=“1” color=“turquoise” column=“22” row=“13”length=“20”><![CDATA[ ]]></nav:field> <nav:field name=“field-13-42”attribute=“1” color=“blue” column=“43” row=“13” length=“40”><![CDATA[]]></nav:field> <nav:field name=“field-14-3” attribute=“1” color=“green”column=“4” row=“14” length=“17”><![CDATA[Postcode . . . ]]></nav:field><nav:field name=“field-14-21” attribute=“1” color=“turquoise”column=“22” row=“14” length=“10”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-14-32” attribute=“1” color=“blue” column=“33” row=“14”length=“50”><![CDATA[ ]]></nav:field> <nav:field name=“field-15-3”attribute=“1” color=“green” column=“4” row=“15”length=“17”><![CDATA[Credit Limit . ]]></nav:field> <nav:fieldname=“field-15-21” attribute=“1” color=“turquoise” column=“22” row=“15”length=“4”><![CDATA[ ])></nav:field> <nav:field name=“field-15-26”attribute=“1” color=“blue” column=“27” row=“15” length=“56”><![CDATA[]]></nav:field> <nav:field name=“field-16-3” attribute=“1” color=“green”column=“4” row=“16” length=“17”><![CDATA[Account Status ]]></nav:field><nav:field name=“field-16-21” attribute=“1” color=“turquoise”column=“22” row=“16” length=“1”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-16-23” attribute=“1” color=“blue” column=“24” row=“16”length=“59”><![CDATA[ ]]></nav:field> <nav:field name=“field-17-3”attribute=“1” color=“green” column=“4” row=“17”length=“17”><![CDATA[Comments . . . ]]></nav:field> <nav:fieldname=“field-17-21” attribute=“1” color=“turquoise” column=“22” row=“17”length=“30”><![CDATA[ ]]></nav:field> <nav:field name=“field-17-52”attribute=“1” color=“blue” column=“53” row=“17” length=“48”><![CDATA[]]></nav:field> <nav:field name=“field-18-21” attribute=“1”color=“turquoise” column=“22” row=“18” length=“30”><![CDATA[]]></nav:field> <nav:field name=“field-18-52” attribute=“1” color=“blue”column=“53” row=“18” length=“48”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-19-21” attribute=“1” color=“turquoise” column=“22” row=“19”length=“30”><![CDATA[ ]]></nav:field> <nav:field name=“field-19-52”attribute=“1” color=“blue” column=“53” row=“19” length=“188”><![CDATA[]]></nav:field> <nav:field name=“field-22-1” attribute=“1” color=“red”column=“2” row=“22” length=“159”><![CDATA[ ]]></nav:field> <nav:fieldname=“field-24-1” attribute=“1” color=“blue” column=“2” row=“24”length=“81”><![CDATA[F1=Help F3=Exit F10=Actions F12=Cancel]]></nav:field> </nav:fields> <nav:formulaname=“NewCustomerScreen-formula”> <nav:areaFormula attribute=“34234”name=“area-2-30” color=“blue” column=“31” row=“3”columns=“12”rows=“1”><![CDATA[4e657720437573746f6d6572]]></nav:areaFormula></nav:formula> <nav:setVariable name=“limit” type=“field” attribute=“1”color=“turquoise” column=“22” row=“15”length=“4”><![CDATA[field-15-22]]></nav:setVariable> <nav:setVariablename=“lastName” type=“field” attribute=“1” color=“turquoise” column=“22”row=“9” length=“20”><![CDATA[field-9-22]]></nav:setVariable><nav:rule.name=“creditLimitRule” binaryOperator=“and”> <nav:conditionname=“Condltion2000” direction=“user2host”> <nav:operand name=“first”type=“field” attribute=“1” color=“turquoise” column=“22” row=“15”length=“4”><![CDATA[field-15-22]]></nav:operand> <nav:operandname=“second”type=“integer”><![CDATA[2000]]></nav:operand><![CDATA[com.netmanage.OnWebIT.navigator.common.GreaterThan]]></nav:condition> <nav:action name=“Send Mail”><nav:operand name=“to”type=“string”><![CDATA[michaelk@netmanage.co.ll]]></nav.operand><nav:operand name=“from” type=“string” /> <nav:operand name=“subject”type=“string” /> <nav:operand name=“body” type=“string” /> <nav:operandname=“smtp-server” type=“string”/><![CDATA[com.netmanage.OnWebIT.navigator.common.SendMail]]></nav:action></nav:rule> </nav:screen>

As shown in FIGS. 4A, 4B, 5 and 6, further implementations of areal-time activity monitoring and reporting system are possible. In onesuch system, depicted in FIG. 4A, a Monitor 102 is deployed between aserver 103 and the clients 106, as shown in FIG. 4A. The server 103,e.g., a CRM (customer relations management) program or a SCM (supplychain management) program, is visible via the Monitor 102 to the client106. The client can be software, such as Java client or SAP client, thatruns as a client to a server-based application, or it can be softwarethat runs as a client to a host on a user PC with an emulator or anotherhost interface solution.

In the system of FIG. 4B, the Monitor 102 is deployed between twoapplications 106 a and 106 b communicating with each other via SOAP orother protocols. Since Web protocols are installed and available for useby all major operating system platforms, HTTP and XML provide an alreadyat-hand solution to the problem of how programs running under differentoperating systems in a network can communicate with each other. Thus,SOAP (Simple Object Access Protocol) is a way for a program running inone kind of operating system (such as Microsoft Windows 2003) tocommunicate with a program in the same or another kind of an operatingsystem (such as Linux) by using the World Wide Web's Hypertext TransferProtocol (HTTP) and its Extensible Markup Language (XML) as themechanisms for information exchange. SOAP specifics how to encode anHTTP header and an XML file so that a program in one computer can call aprogram in another computer and pass it information. SOAP It alsospecifies how the called program can return a response. The Monitorprovide the activity monitoring and reporting utility with its trafficcapture, rules analysis and actions engines 122, 122 and 124,respectively.

As shown in FIG. 5, the Monitor is deployed in an enterprise applicationinterface (EAI) bus between two applications. For instance, the Monitor210 is deployed in a Tibco EAI bus 202 between CRM and a Logisticsapplications, 204 and 206. In this configuration the Monitor 210includes the traffic capture, rules analysis and action engines, 220,222, 224, respectively. Thus the Monitor 210 can sniff allcommunications between these applications as it crosses through the EAIbus but without interfering with the flow of communication. On findingtargeted communications, based on the rules, the Monitor can provide theaction selected for such communications.

In yet another implementation, as shown in FIG. 6, a system with aMonitor include separation of the duties, allowing separate machines toperform separate actions. FIG. 3 shows deployment of the Monitor 150 asa local proxy, a local client software component where traffic throughthe various layers of the operating system is sniffed by this softwarewithout actually interfering with the flow of such communications. Inthis implementation, as the local proxy, the Monitor 150 includes thetraffic engine and rules engines 151 and 152, respectively, but theactions themselves are offloaded to an action server 140 which includesthe action engine 153.

The local Monitor 150 in each user PC 130, is capable of sniffing(obtaining and parsing) the traffic and analyzing it against the rules.If the analysis against the rules produces any indication thatcommunications meet the rules and are therefore targeted, the indicationis reported to the action server which then proceeds to act based on theproper action definition for this circumstance (as illustrated above).In other words, the Monitor's reporting action is offloaded to theaction server, but it still is responsible for alerting the actionserver when it detects a targeted communication involving the particularPC on which it resides. All this, of course, is transparent to the userof the PC and the applications running on it.

It is noted that, in any configuration that involves securecommunications, the Monitor is capable of maintaining the secure line ofcommunications. For example, Transport Layer Security (TLS) and SecureSockets Layer (SSL) are an integral part of most Web browsers (clients)and Web servers. SSL and TLS (at the program layer) are protocols formanaging the security of a message transmission on the Internet. The“sockets” part of the term refers to the sockets method of passing databack and forth between a client and a server program in a network orbetween program layers in the same computer. A protocol such as SSL usesthe public-and-private key encryption system from RSA, which alsoincludes the use of a digital certificate. Thus, if a Web site is on aserver that supports SSL, then SSL can be enabled and specific Web pagescan be identified as requiring SSL access. In this case, the Monitormaintains, without compromising, the security status of these web pages.

Moreover, in any type of implementation, one addition to the real timecommunication tracking and analysis is the substantially instantreporting of targeted activity which such communications may involve.This provides a useful complement to the conventional informationmanagement. Indeed, data warehouses provide a central repository forinformation, solve problems such as data integrity, and provide an easybaseline for building decision support systems (DSS) and OLAP reports.However, the Monitor provides substantially real-time information tocomplement “batch” oriented data extraction processes. The Monitorallows a dynamic and rapid respond to changes, irregularities, risks,etc. The Monitor also provides access to systems with “less structured”or undefined data structure and access to operations where theunderlying system or database in not accessible within a given timeframe and knowledge. The Monitor provides the further advantage ofallowing the user to define and deliver in minutes new connectivitysolutions based on new rules. Additionally, the Monitor allowsdefinition of rules and actions for auditing, based on existingapplication logic and screens and not only on top of raw database staticdata.

How then is a rule attached to a screen? A rule is associated with aspecific screen, or a specific WS (web service) method, under a specificIP and port (the screens inside a host are assumed to be unique, and ifthey are not, it is up to the user to change the wait for text patternto avoid confusion).

It is important to note that management of the rules, includinguploading and reloading, via the Monitor is intended to beuser-intuitive and one which prevents user mistakes. Thus, the Monitoris designed to meet requirements with this in mind. For instance, newrules can be added to an existing set of rules, and the designer will beupdated with the complete set of rules. New rules will be applied to allthe sessions that will be established only after they where activated.Activating or re-loading the sets of rules is done from the systemadministrator's interface (GUI) or console. Every time a change is madeto the rule set on the server, a snapshot of “before change” is backedup on disk with a timestamp. Then, when a change is applied, the newversion is also backed up to the server disk. In one implementation, thesystem can hold a backup of 200 versions, and stale versions are erasedafter a proper alert. The Monitor's rules management will allow, withdouble confirmation, erasure of up to the last 20 versions, but not theentire list. Preferably, if a rule is deleted this deletion will berelevant only for newly established sessions. After the last sessionwhich uses a deleted rule is disconnected, the rule can be released andnot used again.

Moreover, in this configuration, the user interface (GUI) will supportdownloading the history. When the planning (design) time tool connectsto a server, it will first download the existing set of rules and willthen allow adding new or deleting or browsing existing rules. In anyevent, there is no down-time to the system.

For selective or partial uploading of rules, the Monitor is furtherdesigned with specific instructions to the server to load only certainrules, such as only new rules in a given directory, and to apply them torunning sessions.

Note again that rules contain conditions. Specifically, rules containexpressions which combine several (1 or more) atomic conditionsconnected between them with AND or OR logical operator. A condition testresult can be applied with a logical NOT (equivalent to if(!condition(args))). This means that, for simplicity, a conditionreturns a Boolean value.

Associated with the conditions are values and operators. A condition isrelated to a set of one (1) or more values that were extracted from ascreen property (field or area) or a web service (WS) value, or wereentered at design time as literals. This condition will include anoperator that operates on the values that are given (Boolean or otheroperator).

To illustrate, FIG. 7 is a diagram of the relationship between screen/WSand conditions. As shown by indicator ‘A’, a screen points out to one ormore rules, where each rule contains one or more conditions as shown by‘B’. The one or more conditions are connected by logical operator suchas AND, OR, etc. (i.e., there is a Boolean operator between theconditions). As shown by ‘C’, a condition includes a set of operators,where each operator acts on ‘1’ (a unary operator) or other operands.These operands are values fetched from the XML file and from the screensin the session, as shown by ‘D’ and ‘E’. For web service (WS)communications, fields are subject to operators, as further shown by‘E’, such that the rules are attached to WS methods/functions/calls thesame way they are attached to screens in the host environment, as shownby ‘F’ and ‘G’. To instruct the engine on how to locate a field in aweb-service, XPATH into the SOAP structure may be used.

In typical implementations, the Monitor is capable of supportingcustomizable JAVA conditions. This means that additional condition (JAVAclasses) can be developed and added to a server at runtime. The Monitorsystem will allow adding conditions and operators to the package, bothfor run-time evaluation and their related design-time “building” GUI.

Rules and conditions have predefined attributes to control evaluationand behavior. Rule attributes are illustrated in the following table.

DEFAULT ATTRIBUTE TYPE VALUE EXPLANATIONContinue_evaluating_after_turned_true Boolean True When the rule is met(returns true); should we continue evaluating it more?Lmit_number_of_turned_true_times Integer 0 = no How many limit times

The screen images in FIGS. 8-18 show a possible user interlace fordefining rules, conditions and actions. The wizard associated with thisuser interface guides the user through creation of the new rules,conditions and actions. For instance, in FIG. 8 which displays aparticular application screen, the wizard allows the user to select andthen configure a rule for a particular field on the screen. If, as inthis example, the program handles credit accounts, the credit limit isthe selected field for which a rule can be established. Once this fieldis selected, part of the process for defining the rule is selection ofthe variable, as shown in FIG. 9. Again, in this instance we haveselected the “credit limit field” and it is so indicated. Moreover, thefield type can he selected and, in this instance, it is “integer,” asshown by the highlighted item on the right window in the screen. Next,in FIG. 10, the wizard prompts the user to select the value of thefield, where the value is used in the condition. In this example we setthe condition to “value=1000.” As shown in FIG. 11, the condition isfurther defined by selecting an operator which is to apply to thecondition; here we select the operator “greater than,” which meansgreater than the value=1000. As shown in FIG. 12 the wizard prompts theuser to select which conditions the operator should apply to; and itfurther prompts the user to select among the conditions that pertain tothe rule if the operator is to apply to more than one. In this example,however, we show only one condition: “condition1—variable [″]>1000”.Note that the user has the further option of scrolling through andediting any of the selected values as indicated by the “+/−/edit” iconson the screen. In FIG. 13, the wizard prompts the user to select thecondition type, say “existing screen variables,” and in FIG. 14 thewizards prompts the user to select the direction associated with thecondition, namely host-to-user, user-to-host or both directions. Therule just created can be modified as indicated in FIG. 15.

It is noted that, optionally, the rules can be implemented as BPEL(Business Process Execution Language) which is an XML-based languagedesigned to enable task-sharing for a distributed computing or gridcomputing environment—even across multiple organizations—using acombination of Web services. Using BPEL, a programmer formally describesa business process that will take place across the Web in such a waythat any cooperating entity can perform one or more steps in the processthe same way.

Then, once the rule is defined, FIG. 16 shows how the wizard prompts theuser to select the actions which corresponds to this rule. In this casewe select “send mail” as the corresponding action, as shown in FIG. 17.The details of this action are further defined as shown in FIG. 18, say,email to chaelk@netmanage.com.

Thus, returning to FIG. 8, the screen provides fields for the user tofill out which emulate the type of fields used by the application inconducting the business of the organization. For instance, for theapplication that handles credit accounts, as shown, the account number,name and other related fields such as credit limit can be entered. Incombination with the condition value=“1000” and the action=“send mail tochaelk@netmanage.com” from the above-described screens (and as shown onthe left side of this screen), such information, including the creditlimit, can he compared against the condition (value=1000) and acted uponas instructed if the entered credit limit exceeds the value.

Certain design features illustrate implementation of the foregoing. Forinstance, the following table illustrates some basic operators that canbe included in the design:

NUMBER TREATS OF ARGUMENTS ARGUMENTS OPERATION (OPERANDS) FUNCTIONALITYEXAMPLE AS Contains 2 Finds value 1 in Name Strings value 2 contains“kup” Starts with 2 Does value 1 Name Strings start with Value 2 startswith “Mich” Ends with 2 Does value 1 Name Strings end with Value 2 endswith “man” Substring 4 Compares string Name at String in a specificlocation index 3 at lenth and zero- (substring) of 2 equals “ha”based-index to first string to argument In . . . Does value Name inString (dynamic) exists in a set of given [“Kevin”, values “Michael”,“Assi”, “Ido”, “Gil”, “Eran”] > greater 2 Numeric Value 1 > Integer thancomparison value 2 < 2 Numeric Value 1 > Integer comparison value 2 =Integer Ln . . . Does value Number Integer exists in a set of given in[1, 7, 10] values Between 3 Is value between Number Integer between 1and 10

Preferably, in such design, numeric operators support integer, long,float and decimal with decimal point values. Also, when passing anargument like a field value, several attributes are supported,including, for instance, white space trimming, leading zeros trimming,to-lower and to-upper, as well as addition of a general parameter tostring operands and ignoring case in comparisons. Then, inside a screenXML, a special instruction can be defined to scrap a screen area orfield and assign it into a session-variable by name. So, within a singleuser session, a “bag” of variables (hash-table/map) can exist which willbe available for use by condition and actions. Also, an action canassign text and results into a session variable.

As to operands, the values to which a condition can be applied on can bederived from: (1) the current screen (to which the rule is attached);(2) any field from screens visited in this session (in order to allowspecific user, based on account number, to check balance even thoughthey are not always in the same screen). This will be available throughsession variables; (3) any literal from the rule definition (XML); and(4) any system variable (host name/IP etc.). An example of a systemvariable (taken from the system.xml or web.xml for a server) can be theSMTP server for sending emails. This can be referenced by name to asystem variable.

As to condition objects, they serve as the main building blocks for theengine (assuming the engine knows and has a decoder for a givenprotocol). Conditions should be able to receive values and perform thespecific calculation they are built to calculate, based on theparameters (values pass using a mapping XML) and some general attributesspecified at design time (like trim etc.). Thus, in addition to basicconditions that use basic operators, there are some “smart” conditions.The following table illustrates the smart conditions:

SPECIFIC CONDITION DESCRIPTION REQUIREMENTS Screen visited by specificRequires the engine to “client” X times over the last Y track sessionduration and count minutes individual screen/object recognitions, can beskipped if no conditions are based on time (incoming input fromcondition manager component) Client visited a sequence of calls/screensin a specific order Client visited a set of screen, with no particularorder, during the given time frame Composite condition that Compoundcalls other conditions condition JAVA customized condition OperatorsExtension Only used to Condition hold a collection of new operators tobe introduced to the system (Plug-in) User executed a certain keyboardsequence + cursor + on a specific screen

Conditions, rules and actions can have special features. Some conditionswill need to do initialization (such as read instructions from their ownconfiguration, connect to a remote system etc.) For this, each conditionshould have a special method, called by the engine at initializationtime, but typically only once (e.g., OnGlobalInitialize). A parallelmethod (e.g., OnGlobalFinalize) can be defined so as to releaseresources and it should be called before shutdown or when the engine isinstructed to re-load objects.

A condition may have a way to declare itself as reusable, thereby thesystem will create one instance and reuse it instead of creating a newone for each screen. The same should hold for actions. The administratorwill also have an option to instruct the engine to reload objects. Thisoperation will unload all conditions/rules/actions (by calling theirOnGlobalFinalize method or similar) and will re-load the entire rulesXMLS set and initialize.

An action is the operation to be executed if a rule is applied and met.For example, an action is performed if the rule returns a positiveBoolean value (the expression and conditions are met logically). Theaction is preferably well defined with an interface that receives allthe information in the context of the engine, such as the rule and itsdetails, the concurrent information (user, IP of client, server, timewhen stream came in and so on), a snapshot of the original stream, thedata used by the rule, and the state of the connection. This designsupports all types of actions, including “out-of-the-box” actions,plug-in actions and abstract actions.

The so called out-of-the-box actions typically include ‘send email,’‘call HTTP GET/POST,’ ‘call a web-service,’ and ‘start recordingsession’ (as a compressed and encrypted trace file).

The out-of-the-box actions further include ‘report to a log server’(with attributes such as log-server address, severity, level and textualmessage format based on simple XSL). In JAVA, the LOG4J library can beused. This covers also writing to Me and other things. In addition, theout-of-the-box actions include report to HSP. This off-the-shelfmonitoring tool that can be provided with the Monitor will typicallyinclude pre-defined rules for monitoring 3270/5250 sessions. These rulesinclude, for example, a default parameter to report session start andend for all client session, and they include cross data between theuser-IP, session type, login user-name and the host.

The action of reporting to a log uses a number of categories (say,DEBUG, INFO, BUSINESS) and levels of severity (INFO, WARNING, ERROR,FATAL), and it determines which messages should go to which category andlevel. In the default configuration, the report will go to a remotemachine or not report at all in order to avoid reduction of disk spaceover time. Thus, a default configuration, if a local ‘syslog’ server isinstalled or the log is written to file, includes a cyclic the with onemonth history and a download log file (through administrationinterface). At loading time, the download log file includes informationabout the number of screens, rules, and conditions, general hostinformation, and startup parameters (rules directory, log configuration,port etc.). At run time, the log file includes, depending on the level,debug information including session start, end, screen detected, ruleapplied, action, and any admin operation.

Another so called out-of-the-box action is ‘write to DB’ (write todatabase the details of the event by mapping fields to columns in agiven RDBMS system). In JAVA this is done through JDBC (with attributesthat include JDBC driver, database URL, credentials and field mapping).

Further to the above, the Monitor is designed for invoking other actionsuch as ‘send NT message’ (for NT only). Then, as to plug-in actions,the Monitor is designed to allow for additional action objects to bedeployed at run time. Plug-in actions can be added which are written inJAVA. Design time action description might be presented as XML code thatindicates to the designer (NMStudio, planner) things like: name ofaction, description, which input to get from the user, field mappinginstructions, etc. This can be implemented using reflection of JAVAclasses that answer and comply with a specific interface (e.g.,iActionInterface). Preferably, the interface includes the executemethods and is provided with design time and run-time interfaces. Theseinterfaces includes interfaces for setting pre-defined attributes,including: number of re-tries, log object to report failure inexecution, etc.; interface for attaching this action at run-time;interface for adding proprietary parameters (maybe by name-value pairs)like email address to use etc.; interface for synchronic invocation(optional); interface for time-out settings; and interface for receivingall the values from the engine (the rule object instance that triggeredthe action, session stream etc.).

In addition to the foregoing types of actions, this Monitor is designedto support abstract actions. An abstract action is an action which caninvoke real actions via links to actions using an XML schema (e.g., theypoint to a BPEL-WS entity to prompt an action). In other words, abstractactions do nothing except invoke other off-the-shelf and out-of-the-boxactions.

We have mentioned before fields subject to operators in the context ofWS (see FIG. 5 a). Action parameters (much like parameters to acondition) can be of various types, including field, i.e., a referenceto the value of a field in the screen. Other types of action parametersinclude ‘string’ (string of literals), ‘area’ (an area from the screen,including column, row, width, height), and ‘numeric’. Parameters typescan be combined to create values for action (and conditions). Suchconstruction provides also a way to trim leading blanks (left, right,both), trim leading zeros (leading, trailing, all), and convert a stringto its numeric representation.

One additional possibility would be, with an action parameter, to allowreal-time evaluation of JAVA code. Specifically, it would be possible toadd an eclipse plug-in wizard for creating a JAVA actions andconditions. This wizard will also create automatically the XML file codethat is installed at design time. This will inform the designer aboutnew conditions and actions it can allow users to incorporate into arule. The Eclipse plug-in will also auto-generate a JUnit tester for thenew condition or action that was created.

Although the present invention advantageously provides real timeactivity monitoring and reporting, it further provides for sessionrecording, including recording an activity or audit log, and for batchanalysis. To this end, the present invention contemplates, in oneembodiment, the ability to instruct recording of a session, in part orin its entirety, between a host and a client. For session recording, theMonitor copies to a file the entire stream of data. It saves the data tothe file in a compressed form to save space and it encrypts the saveddata to preserve privacy and security. In this case, there would be someseparation of duties and the ability to run the rules evaluator andaction executor in batch over a recorded session. In the design,therefore, the class structure and interface will allow for thisfunctionality, among other things. This design also provides, for rulesevaluation, where specified or non-excluded rules are allowed in thecommand line and checked or non-excluded actions are allowed to execute;and the results written to the log file are the results of allowed rulesevaluations and actions. Then, a batch tool is used to run through asession recording, by client IP, date range, and possibly otherparameters.

One other possibility is to provide the Monitor with a simpleoff-the-shelf default tool (e.g., mOnWebToring tool). For this, it ispossible to use the PHP portal and mOnWebToring interface by HSP. In Webprogramming, PHP is a script language and interpreter that is freelyavailable and used primarily on Linux Web servers. PHP, originallyderived from Personal Home Page Tools, now stands for PHP: HypertextPreprocessor. HSP integration is possible, and the Monitor can bedesigned to allow the same and extended functionality to be achievedwithout any change to the emulator (e.g., where Rumba™ and OnWeb™ hasspecial code that reports to HSP). This also means that the Monitor canbe deployed as an integral part of the Rumba-W2H-HSP package.

As discussed above, a system is configured with an action server inorder to allow the action server to hold more concurrent sessions andwithout any risk achieve separation of duties. This server will be aninstance of the Monitor running in mode USE_AS_ACTION_SERVER orUSE_REMOTE_ACTION_SERVER. In the first mode, IP, Port, all actions andtheir inputs will be sent to the action server to be processed; and inthe second mode, the port number is provided as well. So, one server isintercepting sessions, parsing and evaluating rules, and the second oneruns the actions. It would be possible to cache requests for actions ifthe action server is not available and commit them later when it becomesavailable.

Other modes of operation include USE_IN_SILENCE_MODE. In this mode, theMonitor will write to the log that a condition was met and what actionshould be executed, but it will not execute them.

In connection with separation of duties, as mentioned above inconnection with FIG. 3, one of the system configurations uses localproxy (or a local instance of the Monitor in the user PCs).Specifically, the Monitor is instantiated in users' PCs as a client sidecomponent (C/C++/C#) that is configured as a local proxy. Thecommunication stream to and from the PCs goes through the local Monitor.This component will hold the logic of parsing and evaluating the rulesand will communicate with the action service. The reason for thisconfiguration is to accommodate the preference of some organizations foravoiding overload or addition of resources such as servers and storage.

In terms of deployment, the Monitor can be deployed as a softwarepackage or it can be provided as an appliance (a complete functionalunit with hardware and software). Preferably, its design featuresinclude fully J2EE, scalability to thousand of simultaneous connections,full support for the 3270, 5250 family, design-time tool for complexrule building, full security, administration, logs, encryption of dataand control. Additional design features include full support forweb-services, both in design and in run-time, application support,separation of duties, per-box responsibility, SSL support, replaysupport (preconfigured) and batch investigations support. Furtherimplementation details include testing tool for packaged applications,the ability to run conditions on all repository using adaptors, abilityto connect to a business process engine or to include a BPM engine.

The platform supported by this design is not limited to but includessupport for Linux machines, Windows 2003 server, J2EE application server(e.g., JBOSS 4.x), IBM-WebSphere, etc. For scalability andload-balancing, the Monitor can be implemented in two physical machinesthat function as one virtual server, where XML rules and configurationtiles are uploaded to one location and shared by both. In one instance,the system can support at least 400 concurrent users per-server withstandard 3270 hit load (think time≈30 second). A machine can he definedas a “rules processor” for other machines. This means that a machine canbe configured to accept streams from other appliances (e.g., OnWebITboxes) and process the rules for them.

Additional design considerations of configuration and managementinclude, a separate servlet to allow viewing as HTML/Web, with aseparate user password, the status of the Monitor (e.g., status ofOnWebIT box). The status includes: front IP address and DNS (theaddresses which the clients connects to), up-time, loaded services(types of decoder/protocols supported and installed on this machine,e.g., 3270 and 5250), list of deployed rules (including, optionally, theability to see their specific XML definition or as “pseudo—English”),and accumulated statistics for this run.

Design considerations for system administration, include provision for aseparate administrator log-in to allow submission of maintenancerequests. Such maintenance requests, include ‘service re-start’(requires confirmation and re-type of password if there are connectedusers) and ‘reload objects’ (Actions, conditions, rules). ‘disconnect ofall existing sessions’ (again, with special confirmation), ‘download ofrules definitions (XML files) to client’. ‘upload of rules definition’(replace existing or add), and ‘change passwords for users’.

Rules uploading and UI/Web interfaces are designed to be secured byusername and password. Thus, there arc three types of users:administrator, observer, guest with a default password. If the defaultpassword is not changed, it will be reported daily to the Monitor log.

The Monitor will use the NM-Studio (object Builder C#) as thedesign-time planning tool. And optionally as the deploy interface. Theplanning tool should allow the user to type in a URL for a liveweb-service (WSDL over HTTP) or load a WSDL file from the file-system(disk). The planning tool will parse the definition of the web-serviceand will present it, instead of XML, in a user-friendly GUI that willallow: understanding the separation between a request and the response,identifying parameters and return values and their types, and“clickable” values to attach rules to (the rule type can beautomatically determined according to the TAG type).

It should he noted that all screen recognitions, condition evaluationand action executions, will be performed outside the scope of thesession between the client and the server. To this end, a separatethread or process is used that will not impact the performance and willnot block or break up the connections.

In sum, although the present invention has been described inconsiderable detail with reference to certain preferred versionsthereof, other versions are possible. Therefore, the spirit and scope ofthe appended claims should not be limited to the description of thepreferred versions contained herein.

1. A system for real-time activity monitoring and responsive actions,comprising: a host having an application; a client in communication linkwith and interacting with the applications; and a monitor havingtraffic, rules and actions engines.